fix(tests): Make EventCorrelatorTest timestamps deterministic - #4927

Notes

Remove Thread.sleep(100) from EventCorrelatorTest and make timestamp generation deterministic without depending on elapsed wall-clock time.

The investigation identified two timestamp paths: timestamps supplied by the test for ordinary duplicate events, and timestamps generated internally by EventAggregator for aggregated events.

CI failures

The initial change used now.plusNanos(10) to separate the input timestamps. It passed on Linux and macOS across JDK 11, 17, and 21, and initially on Windows with JDK 11, but intermittent failures appeared on Windows with JDK 17 and 21. Later CI runs also failed on Windows with JDK 11 and 21, specifically in parameterized case [6] (repeated aggregation of similar events).

The failures were not consistently reproducible locally, including on a Windows 10 VM running Eclipse Temurin JDK 11, 17, and 21 with the same Bazel version and --config ci.

Investigation

Instrumenting EventCorrelatorTest and tracing the flow through EventCorrelator, EventAggregator, and EventLogger revealed two different behaviours:

• Duplicate events: EventAggregator returns the original event. EventLogger restores the first observation's firstTimestamp while preserving the incoming lastTimestamp. Explicitly advancing the input timestamp makes these cases deterministic. Increasing the increment to 1 ms addressed the initial failures.
• Aggregated events: When the distinct-message threshold is reached, EventAggregator creates a new event with both timestamps set from its own OffsetDateTime.now() call. On repeated aggregation, EventLogger restores the previous firstTimestamp and retains the new aggregated event's lastTimestamp. If both clock reads return the same value, the assertion fails even though the event is correctly aggregated and counted.

This explains why increasing the input timestamp alone did not fix case [6]: the aggregator replaces those timestamps.

Windows / JDK investigation

After inspecting the OpenJDK source, the failures appear consistent with coarse system-clock resolution on some Windows environments.

• The OpenJDK 11 and 17 Windows implementations inspected use GetSystemTimeAsFileTime(). Its timestamps are represented in 100-nanosecond units, but that representation does not guarantee that successive calls produce distinct values.
• I reproduced the same case [6] assertion failure locally on Linux by temporarily truncating the aggregator's OffsetDateTime.now() values to seconds.

This reproduces the suspected failure mechanism, although the effective clock resolution on the CI runners was not measured directly. It also helps explain why Thread.sleep(100) reduced the failures: it made separate clock readings more likely without guaranteeing them.

Solution

Comparing the Java implementation with Kubernetes' Go client revealed that the Go correlator receives an injectable clock, and its tests use SimpleIntervalClock to advance time predictably. The Java implementation follows similar aggregation logic but read the system clock directly in EventAggregator.

The Java implementation now accepts a Supplier<OffsetDateTime> for aggregation timestamps, while retaining the existing constructors and production behaviour. The default supplier is evaluated on each call:

OffsetDateTime::now

The test supplies an incrementing source instead:

AtomicReference<OffsetDateTime> time =
    new AtomicReference<>(OffsetDateTime.now());

Supplier<OffsetDateTime> advancingTime =
    () -> time.getAndUpdate(t -> t.plusSeconds(1));

EventCorrelator passes the supplier to EventAggregator; EventLogger remains unchanged. The original timestamp assertions are preserved, and the test no longer relies on separate system-clock reads in the aggregation path.

This follows the testability principle used by the Go client without introducing a custom Clock class or changing how production obtains time.

Validation

• Reproduced the intermittent CI assertion locally by simulating a coarse-resolution aggregator clock.
• Verified that EventCorrelatorTest passes with the injected incrementing timestamp source.
• Reverted the temporary clock-truncation experiment.
• Ran the full Bazel test suite locally: 113 test targets passed.

The remaining input-timestamp increment is intentional: ordinary duplicate events preserve the input timestamps, whereas aggregated events use the injected timestamp supplier.